Further attempts at building with .NET 8 #2852

Numpsy · 2025-01-09T11:36:06Z

Description

As #2818, but updated on top of the latest changes and with a couple of extra commits to try to get more tests passing - see further comments for details

Numpsy · 2025-01-09T11:38:29Z

src/test/Fake.Core.IntegrationTests/SimpleHelloWorldTests.fs

              let scenarioPath = resolvePath scenario ""
              // dotnet tool install --version 5.19.0-alpha.local.1 fake-cli --add-source /e/Projects/FAKE/release/dotnetcore/
+
+              // Work around https://github.com/dotnet/sdk/issues/40655 by specifying the tool manifest explicitly


Some of tests in previous runs seemed to be failing with dotnet/sdk#40655, whereby installing the dotnet tool in a subdirectory that contains a tools config file will ignore that file and use the one in the repo root, but then trying to use that tool will use the local config file and then fail.
That issue is marked as resolved, but it still seemed to be occuring in the SDK version used by the tests

Numpsy · 2025-01-09T11:44:05Z

build.fsx

        |> Async.RunSynchronously
        |> List.ofSeq
-        |> List.find (fun product -> product.ProductVersion.Equals("6.0"))
+        |> List.find (fun product -> product.ProductVersion.Equals("8.0"))


I'm not sure what the logic for this (or cachedDotnetSdkReleases.json) should be when updating .NET versions.
The current cachedDotnetSdkReleases.json only contains the .NET 6 releases and that seemed to cause test failures when built as .NET 8 and looking for the v8 SDK versions.
Changing this to 8.0 fixed that, but that might then not be right if fake-cli is multi-targetted at .NET 6 and .NET 8 as the .NET 6 version might still need the list of v6 releases?

github-actions · 2025-01-09T11:54:23Z

Test Results

12 files ±0 12 suites ±0 32m 54s ⏱️ +18s
451 tests ±0 450 ✅ ±0 1 💤 ±0 0 ❌ ±0
1 287 runs ±0 1 284 ✅ ±0 3 💤 ±0 0 ❌ ±0

Results for commit ae027fd. ± Comparison against base commit 74e1e6f.

This pull request removes 3 and adds 3 tests. Note that renamed tests count towards both.

[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.300 SDK version assemblies and resolve runtime version from cached file]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.300 SDK version assemblies]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.301 SDK version assemblies]

[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.400 SDK version assemblies and resolve runtime version from cached file]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.400 SDK version assemblies]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.401 SDK version assemblies]

♻️ This comment has been updated with latest results.

Numpsy · 2025-01-09T11:58:25Z

The remaining failures are in the TemplateIntegrationTests, with errors like

25h[11:48:10 ERR] Fake.DotNet.Cli.IntegrationTests.TemplateTests.can install and run the template.fails to build a target that doesn't exist failed in 00:00:09.6230000. 
Expected the message 'Target Nonexistent is not defined' but got: No exact match of product releases 8.0.401 found.
No product release found for 8.0.401. Maybe a pre-release? Returning all the versions.
No exact match of product releases 8.0.404 found.
No product release found for 8.0.404. Maybe a pre-release? Returning all the versions.
There was a problem while setting up the environment:
-> Could not find referenced assemblies in path: '[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.36\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.35\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.33\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.32\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.31\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.30\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.29\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.28\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.27\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.26\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.25\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.24\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.23\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.22\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.21\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.20\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.19\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.18\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.16\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.15\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.14\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.13\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.12\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.11\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.10\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.9\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.8\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.7\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.6\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.4\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.3\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.2\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.1\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-rc.2.21480.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-rc.1.21451.13\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.7.21377.19\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.6.21352.12\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.5.21301.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.4.21253.7\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.3.21201.4\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.2.21154.6\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.1.21102.12\ref\net6.0]', please check installed SDK and runtime versions

and I'm not sure if this is really a problem with the new stuff, or if it's because it's trying to use the 6.1.3 release to test the templates, and failing when running as .NET 8? (I suppose it shou;dn't be looking at the 6.0 assemblies when running as 8.0)

Thorium · 2025-07-17T09:50:53Z

I expect that there is a chicken-and-egg problem, and the integration tests are actually restoring the .NET6 fake to try compiling .NET8, instead of referring to the just built .NET 8 version.

I tried this branch locally (Numpsy/new8-build-bump-roll-tests-2) on my machine, and my observations are here:

src\app\fake-cli\bin\Release\ has now net6.0 and net8.0 paths. Can a dotnet tool even have multiple target frameworks? Or should we just accept that FAKE 6.1.3 is working well for .NET6 projects and from now on everything else is .NET 8 only?

I run on my Windows machine dotnet build, and then from the actions:
dotnet tool install fake-cli --add-source "./src/app/fake-cli/bin/Debug" --add-source "./src/app/fake-cli/bin/Release" --version 1.0.0-1

It turned out that this didn't work properly. So I removed the Clean-task and called fake manually:

C:\git\FAKE>src\app\fake-cli\bin\Debug\net8.0\fake-cli -v build -e FAKE_DETAILED_ERRORS=true

And behold, all the integration tests went through, after painfully long half-an-hour later:

Where it did finally fail is:

dotnet.exe  deb --runtime linux-x64 --framework net8.0 --configuration Release --output "C:\git\FAKE\release\dotnetcore" --no-restore`

error NETSDK1045: The current .NET SDK does not support targeting .NET 8.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 8.0. [C:\git\FAKE\src\app\fake-cl

So basically, dotnet deb tool has to be updated from 0.1.220 to version 0.1.232

FAKE/.config/dotnet-tools.json

Line 6 in 73fc961

"version": "0.1.220",

...and that's it, I think we could consider merging this and releasing a beta or new major version.

xperiandri · 2025-07-17T12:51:48Z

Can a dotnet tool even have multiple target frameworks?

@Thorium yes it can.
But there are some challenges with that.
You can see my changes in this PR to test that the older framework works fsprojects/FSharpLint#748

Numpsy · 2025-07-17T13:11:26Z

well for .NET6 projects and from now on everything else is .NET 8 only?

Whether there's any benefit to supporting .NET 6 in fake-cli any more is another question, and given the amount of pain in testing it all, just doing 8 seems simpler for a new major release?

.NET 10 is on the horizon, so making sure it works for that going forward seems more important than keeping 6 working in new versions. (My personal opinion anyway).

I'll see about rebasing it and fixing the conflicts anyway

Thorium · 2025-07-17T13:25:11Z

Many projects use a separate non-FAKE fsproj as a build-project and reference the FAKE libraries, and there I see value in having .NET6 support kept.

But the fake-cli tool, I think, could target only the NET8 (or even 10 later).

xperiandri · 2025-07-17T14:35:43Z

Then it will be impossible to run it unless you have the latest SDK installed

Numpsy · 2025-07-17T15:36:51Z

Then it will be impossible to run it unless you have the latest SDK installed

The 'DNX' stuff that MS are talking about with .NET 10 (https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview6/sdk.md#platform-specific-net-tools) could maybe help if the tool could be self contained, but that's a work in progress so it remains to be seen

Numpsy · 2025-07-17T16:32:04Z

On the subject of targetting multiple .NET versions in fake-cli, re-reading the old comments reminded me of the situation with cachedDotnetSdkReleases.json - i.e., if the tool i smulti-targetted, you might need multiple versions of that file for different .NET versions?

Numpsy · 2025-07-17T19:07:11Z

@Thorium I didn't see your other PR until after i'd rebased the changes to fix the merge conflicts, which caused conflicts in that, so I've cherry picked your dotnet-deb update straight into this PR

Thorium · 2025-07-18T08:35:27Z

I think this file https://github.com/fsprojects/FAKE/blob/master/src/template/fake-template/Content/.config/dotnet-tools.json
says "use the nuget version of FAKE in the integration test templates", which causes any major changes to FAKE (like .NET update) to break the integration tests, because the NuGet version doesn't have these changes yet.

But I'm not sure if there is any workaround possible.

Thorium · 2025-07-18T10:30:56Z

One more thing: Because the system uses FSharp.Compiler.Service v43.8, the fsdocs-tool has to be upgraded from 16 to 20, to make GenerateDocs task pass.

Edit: Updated my PR, but you can also just do dotnet tool update fsdocs-tool instead.

After this, my local build does pass:

xperiandri · 2025-10-21T08:10:21Z

@arialdomartini

build.fsx

Numpsy · 2025-10-26T10:51:21Z

General question about all the FAKE modules - should they all be both .NET 6 and .NET 8, or just NET 8? (or maybe only 6 if they don't have any dependencies where it matters?)

src/app/fake-cli/fake-cli.fsproj

Numpsy · 2025-10-26T10:56:15Z

Otherwise the basic question is whether this should be turned into 8.0.0 alpha 1 and then the templates and tests fixed on top of that, or if it's worth trying something more minimal with just a .NET 8 / v8 build of fake-cli and then doing the modules afterwards.

Numpsy · 2025-10-26T23:15:13Z

I expect that there is a chicken-and-egg problem, and the integration tests are actually restoring the .NET6 fake to try compiling .NET8, instead of referring to the just built .NET 8 version.

I tried this branch locally (Numpsy/new8-build-bump-roll-tests-2) on my machine, and my observations are here:

src\app\fake-cli\bin\Release\ has now net6.0 and net8.0 paths. Can a dotnet tool even have multiple target frameworks? Or should we just accept that FAKE 6.1.3 is working well for .NET6 projects and from now on everything else is .NET 8 only?

I run on my Windows machine dotnet build, and then from the actions: dotnet tool install fake-cli --add-source "./src/app/fake-cli/bin/Debug" --add-source "./src/app/fake-cli/bin/Release" --version 1.0.0-1

It turned out that this didn't work properly. So I removed the Clean-task and called fake manually:

C:\git\FAKE>src\app\fake-cli\bin\Debug\net8.0\fake-cli -v build -e FAKE_DETAILED_ERRORS=true

And behold, all the integration tests went through, after painfully long half-an-hour later:

Where it did finally fail is:
dotnet.exe  deb --runtime linux-x64 --framework net8.0 --configuration Release --output "C:\git\FAKE\release\dotnetcore" --no-restore`

error NETSDK1045: The current .NET SDK does not support targeting .NET 8.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 8.0. [C:\git\FAKE\src\app\fake-cl
So basically, dotnet deb tool has to be updated from 0.1.220 to version 0.1.232

FAKE/.config/dotnet-tools.json

Line 6 in 73fc961

"version": "0.1.220",

...and that's it, I think we could consider merging this and releasing a beta or new major version.

It appears to work (all integration tests pass) if the .NET 6 runtime files are present in the local .NET install created by the tests, but not otherwise.

So

If i run the tests from this branch on a clean setup, if fails as the CI does.

If I run the build from the master branch, it installs the .NET 6 libs into %AppData%\Local\Microsoft\dotnet to run the .NET 6 tests, and leaves the files there.

If I then run the tests from this branch again, it installs the .NET 8 libs into %AppData%\Local\Microsoft\dotnet alongside the .NET 6 libs rather than replacing them, and the template integration tests find those and the tests pass.

Having .NET 6 installed in the default system location doesn't effect this as the tests are looking in the custom install location.

SteveGilham · 2025-10-27T10:24:22Z

As net6.0 is past end of support, as is net7.0, after any necessary bridging release to get to net8.0, it would make sense to drop all mention of net6.0 - and work to prepare for net10.0 so we don't have an end of support crisis this time next year as both net8.0 and net9.0 are superseded on 10-Nov-26.

Let us hope that that process that time can be made as easy as "for a bridging release add mention of net10.0 at these points in the build system, the project targets and the code, then enable this bridging flag; for real net10.0 release, remove net8.0 and clear the flag. Lather, rinse repeat for net12.0, net14.0 ..."

Numpsy · 2025-10-27T21:22:29Z

So, I tried changing the template tests to create a test local nuget.config file which points at the locally built nuget packages, such that the tests use the local v8 alpha build instead of using the 6.1.4 builds from nuget.org, and that has made the tests pass.

Numpsy · 2025-10-27T21:25:53Z

src/template/fake-template/Content/.template.config/template.json

        "args": {
            "executable": "dotnet",
-            "args": "tool update fake-cli"
+            "args": "tool update fake-cli --prerelease"


One of the tests needs the --prerelease here otherwise it tries to replace the v8 alpha build with the released 6.1.4 build and fails.
I think it's fine for the v8 alpha template to have prerelrease enabled, as long as it's changed before the final release

Numpsy · 2025-10-27T21:27:45Z

src/test/Fake.DotNet.Cli.IntegrationTests/TemplateTests.fs

+        <packageSources>
+        <clear />
+        <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
+        <add key="localBuild" value="{nugetPackageFolder}" />


This allows the tests to find the locally built v8-alpha fake-cli package instead of always using the 6.1.4 version off nuget.org, which lets the test pass by using the .NET 8 version instead of the .NET 6 version

SteveGilham · 2025-10-28T15:39:26Z

src/app/Fake.Runtime/SdkAssemblyResolver.fs

Although RuntimeAssemblyVersions now defaults to a 2-element list, this is actually pointless as everything derived from the value starts by goes through |> Seq.head - lines 65-68 of this file. Retaining the sequence nature may help with the net10.0 (and future) update.

Lines 283, 295 still refer to a method net60releases; this could do with renaming when it refers to net8.0 SDKs.

I'm not sure if it should be both 6/8 now, or just 8 (will something running on .NET 8 ever want the .NET 6 libs?)
@Thorium ?

Maybe line 51 should be ReleaseVersion "8.0.0" as well

Lines 283, 295 still refer to a method net60releases; this could do with renaming when it refers to net8.0 SDKs.

renamed to netReleases

RELEASE_NOTES.md

Change global.json .NET 6 to 8 Search and replace targetframeworks from fsproj files to add net8.0 Add net8.0 to paket.dependencies dotnet paket install to find .NET8 compatible dependencies Expecto had to be hardcoded for now, because some tests are running on netstandard2.0 library (hopefully we can update this separately later) MSBuild.StructuredLogger problem: DisableInternalBinLog = true had to be added to build.fsx NuGet commands (hopefully we can update this separately later) A few places of code had new overrides so had to explicitly type to strings SdkAssemblyResolver to default .NET 8 as well Readme update GitHub pipeline configs: Add .NET 8 install.

…l has to be upgraded from 16 to 20, to make GenerateDocs task pass.

…the 8.0.0 alpha build Instead of pulling the 6.1.X build off NuGet.org. This might bootstrap the tests enough to get them all passing

…n 8.0.0 instead of 6.0.0

Because it might be .NET 8 releases now

… up the fix for GHSA-w3q9-fxm7-j8fq Also updates transitive dependencies on System.Text.Json to

Numpsy commented Jan 9, 2025

View reviewed changes

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 0364d81 to 233081b Compare July 17, 2025 17:31

Numpsy marked this pull request as ready for review July 17, 2025 19:07

Numpsy mentioned this pull request Sep 14, 2025

Update dotnet-deb to 0.1.232 #2869

Merged

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 62084b1 to 7b0784d Compare October 21, 2025 10:09

Numpsy mentioned this pull request Oct 21, 2025

Using FAKE with recent frameworks (8.0 and 9.0) #2862

Open

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 7b0784d to 41a04b5 Compare October 25, 2025 21:42

Numpsy commented Oct 26, 2025

View reviewed changes

build.fsx Outdated Show resolved Hide resolved

Numpsy commented Oct 26, 2025

View reviewed changes

src/app/fake-cli/fake-cli.fsproj Outdated Show resolved Hide resolved

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 41a04b5 to ba8e1ed Compare October 26, 2025 13:47

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch 2 times, most recently from fe22252 to 21017b8 Compare October 27, 2025 20:37

Numpsy commented Oct 27, 2025

View reviewed changes

SteveGilham reviewed Oct 28, 2025

View reviewed changes

xperiandri requested changes Oct 28, 2025

View reviewed changes

RELEASE_NOTES.md Outdated Show resolved Hide resolved

Thorium and others added 14 commits October 29, 2025 09:38

try to run integration-tests with net6.0

208899d

uninstall didn't seem to work well anyway

c62a045

publish both test-artifacts, ensure test DirectorySeparatorChar

be40973

parentheses added

80dfdb8

integration tests back to 8

63d4dba

typo fix

94ae022

fix merge

4823114

Try using the .NET 8 SDK for the resolver tests

c27681e

Try to work around dotnet/sdk#40655

944959f

Because the system uses FSharp.Compiler.Service v43.8, the fsdocs-too…

090d7b2

…l has to be upgraded from 16 to 20, to make GenerateDocs task pass.

Fix merge

47f3859

Try to get the template integration tests working by making them use …

960d0e6

…the 8.0.0 alpha build Instead of pulling the 6.1.X build off NuGet.org. This might bootstrap the tests enough to get them all passing

update

439ba10

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 21017b8 to 439ba10 Compare October 29, 2025 09:42

Numpsy added 3 commits October 30, 2025 15:19

Change SdkAssemblyResolver.SdkVersions to take an empty string to mea…

d47584d

…n 8.0.0 instead of 6.0.0

In GetProductReleasesForSdk(), rename 'net60releases' to 'netReleases'

e26ef2a

Because it might be .NET 8 releases now

Update the Microsoft.Build libraries from 17.11.4 to 17.11.48 to pick…

ae027fd

… up the fix for GHSA-w3q9-fxm7-j8fq Also updates transitive dependencies on System.Text.Json to

Further attempts at building with .NET 8 #2852

Are you sure you want to change the base?

Further attempts at building with .NET 8 #2852

Uh oh!

Conversation

Numpsy commented Jan 9, 2025

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jan 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Numpsy commented Jan 9, 2025

Uh oh!

Thorium commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xperiandri commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Thorium commented Jul 17, 2025

Uh oh!

xperiandri commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Thorium commented Jul 18, 2025

Uh oh!

Thorium commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xperiandri commented Oct 21, 2025

Uh oh!

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

SteveGilham commented Oct 27, 2025

Uh oh!

Numpsy commented Oct 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Jan 9, 2025 •

edited

Loading

Thorium commented Jul 17, 2025 •

edited

Loading

xperiandri commented Jul 17, 2025 •

edited

Loading

Thorium commented Jul 18, 2025 •

edited

Loading